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Overview 


Introduction 


Purpose 


Objectives 


Benefits 


The  Software  Engineering  Institute  (SEI),  a  federally  funded  research  and  develop¬ 
ment  center  and  part  of  Carnegie  Mellon  University  in  Pittsburgh,  Pennsylvania, 
has  been  formally  studying  and  developing  risk  management  concepts  since  Janu¬ 
ary  1990  as  an  efficient  means  to  improve  the  success  of  programs  developing  soft¬ 
ware-intensive  systems. 

Team  Risk  Management  is  a  new  paradigm  for  managing  programs  or  projects  by 
developing  a  shared  »>»-oduct  vision,  focused  on  results,  and  using  the  principles  and 
tools  of  risk  mana  i./  *0  cooperatively  manage  risks  and  opportunities. 


This  report  will  familiari^i  you  with  the  concept  of  Team  Risk  Management  by  pro¬ 
viding  a  description  of  the  overaP  process  that  engages  both  the  customer  and  sup¬ 
plier  in  a  cooperative  framework  using  explicit  methods  to  manage  project  risks. 


After  reading  this  report  you  should  be  able  to 

•  understand  the  Team  Risk  Management  concept 

•  differentiate  Team  Risk  Management  from  risk  management 

•  answer  the  question,  “Is  it  useful  to  me?” 

•  know  what  is  required  to  initiate  Team  Risk  Management 


Your  organization  or  project  will  derive  the  following  benefits  from  Team  Risk 
Management. 

•  Improve  customer-supplier  and  internal  communication. 

•  Use  a  concise  approach  and  systematic  discipline  that  carries  over  to  other 
activities. 

•  Enable  your  program  or  project  to  face  issues  that  before  tended  to  be  too 
abstract  to  handle. 

•  Improve  design  and  fundamentally  alter  development  decisions. 

•  Provide  more  focus  to  program  or  project  activity. 

•  Increase  product  development  predictability  -  reduce  surprises. 
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Risk  Terms  and  Definitions 

Background  There  are  a  number  of  definitions  and  uses  for  the  term  risk,  but  no  universally  ac¬ 

cepted  definition. 

What  all  definitions  have  in  common  is  agreement  that  risk  has  two  characteristics 
[Kirkpatrick  92,  p.7]: 

•  uncertainty  -  an  event  may  or  may  not  happen 

•  loss  -  an  event  has  unwanted  consequences  or  losses 

Rowe  Risk  is  the  potential  for  realization  of  unwanted  negative  consequences  of  an  event 

Definition  [Rowe  88,  p.  24], 

Lowrance  Risk  is  the  measure  of  the  probability  and  severity  of  adverse  effects  [Lowrance  76, 

Definition  p.  94]. 

Webster’s  Risk  is  the  possibility  of  suffering  loss,  injury,  disadvantage,  or  destruction  [Web- 

Definition  ster’s  Dictionary  81,  p.  1961]. 

SEI  Definition  The  SEI  uses  the  Webster’s  definition  of  risk. 

Risk  is  the  possibility  of  suffering  loss. 

In  a  development  program,  the  loss  could  be  in  the  form  of  diminished  quality  of 
the  end  product,  increased  costs,  delayed  completion,  or  failure. 

SEI  Statement  For  a  risk  to  be  understandable,  it  must  be  expressed  clearly.  Such  a  statement  must 
of  Risk  include 

•  a  description  of  the  current  conditions  that  may  lead  to  the  loss 

•  a  description  of  the  loss 


Example  of 
Risk 


Non-Example 
of  Risk 


Team 


Example  of 
Team 


Customer 


Company  XYZ  has  just  introduced  object-oriented  technology  into  its  organization. 
They  see  this  new  technology  as  having  considerable  competitive  advantage  in  the 
future  because  of  its  potential  for  asset  reuse  in  their  major  product  lines.  Although 
many  people  within  the  organization  are  familiar  with  the  technology,  it  has  not 
been  part  of  their  development  process,  and  their  people  have  very  little  experience 
and  training  in  the  technology’s  application. 

The  risk  is:  Given  the  lack  of  experience  and  training,  there  is  a  possibility  that  as¬ 
set  reuse  will  not  be  realized  before  losing  market  share. 


Company  ABC  is  developing  a  flight  control  system.  During  system  integration 
testing  the  flight  control  system  becomes  unstable  because  processing  of  the  control 
function  is  not  quick  enough  during  a  specific  maneuver  sequence. 

This  is  not  a  risk  since  the  event  is  a  certainty  -  it  is  a  problem. 


A  team  is  a  small  number  of  people  with  complementary  skills  who  are  committed 
to  a  common  purpose,  set  of  performance  goals,  and  approach  for  which  they  hold 
themselves  mutually  accountable  [Katzenbach  93,  p.  1 12]. 


An  integrated  product  team  includes  representatives  from  developer,  marketers, 
customers,  and  users  all  working  toward  and  accountable  for  the  successful  devel¬ 
opment  of  a  product  on  time  and  within  budget. 


The  term  customer  refers  to  the  organization  acquiring  systems  (typically  designat¬ 
ed  as  programs  or  projects)  and  is  responsible  for 

•  defining  the  requirements 

•  obtaining  funding 

•  selecting  the  supplier/contractor 

•  negotiating  the  contract 

•  accepting  the  product  [Kirkpatrick  92] 

In  this  report,  the  term  government  is  used  as  a  specific  example  of  a  customer. 
Note:  Project  and  program  are  considered  synonymous  terms  in  this  report. 
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Supplier 


The  term  supplier  refers  to  the  organization  developing  and  producing  the  system 
and  is  responsible  for  implementing  the  requirements  under  the  terms  of  the  con¬ 
tract,  which  include  cost  and  schedule  [Kirkpatrick  92]. 

In  this  document,  the  term  contractor  is  used  as  a  specific  example  of  a  supplier. 
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Risk  Management 


Background  The  term  risk  management  is  applied  in  a  number  of  diverse  disciplines.  People  in 

the  fields  of  statistics,  economics,  psychology,  social  sciences,  biology,  engineer¬ 
ing,  toxicology,  systems  analysis,  operations  research,  and  decision  theory,  to  name 
a  few,  have  been  addressing  the  field  of  risk  management  [Kirkpatrick  92,  p.  8]. 

Kloman  summarized  the  meaning  of  risk  management  in  the  context  of  a  number 
of  different  disciplines  in  an  article  for  Risk  Analysis: 

What  is  risk  management?  To  many  social  analysts,  politicians,  and 
academics  it  is  the  management  of  environmental  and  nuclear  risks, 
those  technology-generated  macro-risks  that  appear  to  threaten  our 
existence.  To  bankers  and  financial  officers  it  is  the  sophisticated 
use  of  such  techniques  as  currency  hedging  and  interest  rate  swaps. 

To  insurance  buyers  and  sellers  it  is  coordination  of  insurable  risks 
and  the  reduction  of  insurance  costs.  To  hospital  administrators  it 
may  mean  ‘quality  assurance.’  To  safety  professionals  it  is  reducing 
accidents  and  injuries  [Kloman  90,  p.  20]. 

Kloman  Risk  management  is  a  discipline  for  living  with  the  possibility  that  future  events 

Paraphrase  of  may  cause  adverse  effects  [IGoman  90,  p.  203]. 

Rowe 


SEI  Definition  Risk  management  sets  forth  a  discipline  and  environment  of  proactive  decisions 
and  actions  to 

1.  assess  continuously  what  can  go  wrong  (risks). 

2.  determine  what  risks  are  important  to  deal  with. 

3.  implement  strategies  to  deal  with  those  risk. 

Note:  The  SEI  definition  emphasizes  the  continuous  aspect  of  risk  management. 


Example  When  using  true  risk  management,  risks  are  assessed  continuously  and  used  for  de¬ 

cision  making  in  all  phases  of  a  project.  Risks  are  carried  forward  and  dealt  with 
until  they  are  resolved,  or  until  they  turn  into  problems  and  are  handled  as  such. 


Non*Example  In  some  programs,  risks  are  assessed  only  once  during  initial  project  planning.  Ma¬ 
jor  risks  are  identified  and  mitigated,  but  risks  are  never  explicitly  reviewed  again. 

This  is  not  an  example  of  risk  management  because  risks  would  not  be  continuously 
assessed  and  new  risks  continuously  identified. 
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Principles  of  These  five  principles  provide  a  framework  to  accomplish  effective  risk  manage- 

Risk  ment. 

Management 


Principle 

Effective  risk  management  requires 

Global  perspective 

•  Viewing  software  development  within 
the  context  of  the  larger  systems-level 
definition,  design,  and  development. 

•  Recognizing  both  the  potential  value  of 
opportunity  and  the  potential  impact  of 
adverse  effects. 

Forward-looking  view 

•  Thinking  toward  tomorrow,  identifying 
uncertainties,  anticipating  potential 
outcomes. 

•  Managing  project  resources  and 
activities  while  anticipating 
uncertainties. 

Open  communication 

•  Encouraging  free-flowing  information  at 
and  between  all  project  levels. 

•  Enabling  formal,  informal,  and 
impromptu  communication. 

•  Using  processes  that  value  the  individual 
voice  (bringing  unique  knowledge  and 
insight  to  identifying  and  managing 
risk). 

Integrated  management 

•  Making  risk  management  an  integral  and 
vital  part  of  project  management. 

•  Adapting  risk  management  methods  and 
tools  to  a  project’s  infrastructure  and 
culture. 

Continuous  process 

•  Sustaining  constant  vigilance. 

•  Identifying  and  managing  risks  routinely 
throughout  all  phases  of  the  project’s  life 
cycle. 
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SEI  Risk  Management  Paradigm 


Risk 

Management 

Paradigm 


The  SEI  Risk  Management  Paradigm  is  depicted  below  [Van  Scoy  92,  p.  9],  The 
paradigm  illustrates  a  set  of  functions  that  are  identified  as  continuous  activities 
throughout  the  life  cycle  of  a  project. 


Functions  of  The  functions  of  risk  management  are  described  below  [SEI  92,  Higuera  93].  Each 

Risk  risk  nominally  goes  through  these  functions  sequentially  but  the  activity  occurs 

Management  continuously,  concurrently,  and  iteratively  throughout  the  project  life  cycle  (e.g., 

planning  for  one  risk  may  identify  another). 


Function 

Description 

Identify 

Search  for  and  locate  risks  before  they  become  problems. 

Analyze 

Process  risk  data  into  decision-making  information. 
Determine  the  values  of  impact,  likelihood,  and  time- 
frame. 

Plan 

Translate  risk  information  into  decisions  and  actions 
(both  present  and  future)  and  implement  those  actions. 

Track 

Monitor  risk  indicators  and  mitigation  actions. 

Control 

Correct  for  deviations  from  the  planned  risk  actions. 

Communicate 

Provide  information  and  feedback  internal  and  external  to 
the  project  on  the  risk  activities,  current  risks,  and 
emerging  risks. 

Npi?:  Communication  happens  throughout  all  the 
functions  of  risk  management. 
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How  Risk  Management  Fits  with  Project 
Management 

Introduction  Risk  management  integrates  readily  with  the  functions  of  project  management,  and 

adds  new  power  and  scope  to  those  functions. 

Project  Project  management  may  be  thought  of  as  a  set  of  people-oriented,  integrated  activ- 

Management  iiies  as  shown  below  [Kezbom  89,  p.  3-6]. 


Project 

Management 

Functions 


The  functions  of  project  management  are  described  below  [Kezbom  89,  p.  41. 


Function 

Description 

Planning 

Define  desired  results,  strategy,  course  of  action, 
and  checkpoints. 

Organizing 

Establish  structure,  roles  and  responsibilities,  and 
allocate  resources. 

Directing 

Communicate,  delegate,  and  coordinate  activities. 

Controlling 

Provide  measurement,  feedback,  evaluation,  and 
adjustment. 
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What  Risk 
Managoment 
Adds  to 
Project 
Management 


Risk  management  looks  ahead  in  the  project  and  adds  a  structured  approach  for  the 
identification  and  analysis  of  risks  to  begin  planning.  Risk  planning  adds  the  proac¬ 
tive  perspective  of  alternatives  and  contingencies  to  mitigate  risk,  whereas  the 
“Track”  and  “Control”  functions  of  the  risk  management  paradigm  merges  with  the 
controlling  function  in  project  management. 

In  addition,  the  five  principles  of  risk  management  (global  perspective,  forward- 
looking  view,  open  communication,  integrated  management,  continuous  process) 
strengthen  the  proactive  and  systematic  nature  of  effective  project  management. 


Integrated 

Project 

Management 

Concept 


The  combination  of  these  two  concepts  is  shown  in  the  diagram  below. 


Integrated  Project  Management 
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Team  Risk  Management  Principles 


Team  Activities 


Principles  of 
Team  Risk 
Management 


Team  Risk  Management  extends  risk  management  with  team-oriented  activities  in¬ 
volving  the  customer  and  supplier  (e.g.,  government  and  contractor)  where  customer 
and  supplier  apply  methods  together. 


Customer  Surlier 

The  first  two  principles  below  added  to  the  five  principles  of  risk  management  con¬ 
stitute  the  principles  of  Team  Risk  Management.  Open  communications  are  further 
enhanced  when  customer  and  supplier  use  consensus-based  processes  that  also  value 
the  individual  voice. 


Principle 


Shared  product  vision 


Teamwork 


Global  perspective 


Effective  Team  Risk  Management 
requires: 

•  Sharing  a  product  vision  based  upon 
common  purpose,  shared  ownership,  and 
collective  commitment. 

•  Focusing  on  results. 

•  Working  cooperatively  to  achieve  a 
common  goal. 

•  Pooling  talent,  skills,  and  knowledge. 

widim  the  systms  context. 


icw 


_  .... 


•  Enti 


ccommimeiaion. 

Using  consensus-based  processes 
between  customer  and  supplier  that 
value  the  individual  voice. 


integrated  managein 
Conidnaous  pirocess 


Managiag  risks  routinely. 


Team  Risk  Management  Functions 

Introduction  Team  Risk  Management  establishes  an  environment  built  on  a  set  of  processes, 

methods,  and  tools  that  enable  the  customer  and  supplier  to  work  together  coopera¬ 
tively,  continuously  managing  risks  throughout  the  life  cycle  of  a  software-depen¬ 
dent  development  program.  It  is  built  on  a  foundation  of  the  principles  of  risk  man¬ 
agement  and  the  philosophy  of  cooperative  teams. 

Team  Risk  Team  Risk  Management  is  a  paradigm  for  managing  programs  or  projects  by  devel- 

Management  oping  a  shared  product  vision,  focused  on  results,  and  using  the  principles  and  tools 

Defined  of  risk  management  to  cooperatively  manage  risks  and  opportunities. 

Adding  Team  Team  Risk  Management  implements  the  functions  of  risk  management  that  are  il- 

To  Risk  lustrated  in  the  SEI  Risk  Paradigm  by  adding  the  principles  of  shared  product  vision 

Management  and  teamwork  to  make  up  the  functions  of  Team  Risk  Management. 

Team  Risk  Management  adds  two  new  functions,  Initiate  and  Team,  to  recognize 
both  the  required  cultural  paradigm  shift  and  the  emphasis  on  teamwork. 

Risk  Paradigm  ^  Team  Risk  Management 

Functions 

•  Initiate 

•  Team* 

•  Identify 

•  Analyze 

•  Plan 

•  Track 

•  Control 


*NQte:Team  is  used  as  an  action  verb. 


Team  Risk 

Management 

Model 


The  Team  Risk  Management  model  is  shown  below.  Each  function  has  a  set  of  ac¬ 
tivities  that  are  backed  by  processes,  methods,  and  tools  that  encourage  and  enhance 
communication  and  teamwork.  Two  additional  functions.  Initiate  and  Team,  de¬ 
scribed  below  complete  the  model. 
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Team  Risk 

Management 

Functions 


The  table  below  describes  how  Team  Risk  Management  implements  the  risk  man¬ 
agement  functions.  Communication  is  an  integral  part  of  all  these  activities.  Howev¬ 
er,  explicit  formal  activities  provide  excellent  communication  opportunities  for  both 
customer  and  supplier. 


Function 

Description 

Initiate  , 

4 

Recognize  the  need  and  commit  to  create  the  team  culture. 
Either  customer  or  supplier  may  initiate  team  activity,  but 
both  must  conunit  to  sustain  the  teams. 

Team 

Formalize  the  customer  and  supplier  team  and  merge  the 
viewpoints  to  form  a  shared  product  vision.  Systematic 
methods  periodically  and  jointly  applied  establish  a  shared 
understanding  of  the  project  risks  and  their  relative 
importance.  Establish  joint  information  base  of  risks, 
priorities,  metrics,  and  action  plans. 

Example  methods: 

•  team  building 

Identify 

Search  for  and  locate  risks  before  they  become  problems. 
Identify  risks  and  set  project  priorities  to  arrive  at  a  joint 
understanding  of  what  is  important. 

Identify  new  risks  and  changes. 

Example  methods: 

•  reviewing  lists  of  existing  risks  and  known  or  anticipated 
changes 

•  structured  interviews  applied  to  teams  periodically,  such 
as  at  major  milestones 

Team  Risk 
Management 
Functions, 
continued 


Function 


Analyze 


\Q3 


Track 


Description 


Process  risk  data  into  decision-making  information.  Risk 
analysis  is  performed  to  determine  what  is  important  to  the 
project,  to  set  priorities,  and  to  allocate  resources. 

Group  risks  and  quantify  impact,  likelihood,  and  time  frame. 

Example  methods: 

•  affinity  grouping  to  classify 

•  voting  to  set  priorities 

•  pairwise  comparison  to  set  priorities 


Translate  risk  information  into  decisions  and  mitigating 
actions  (both  present  and  future)  and  implement  those  actions. 
Joint  risks  require  a  team  process  to  develop  mitigation  plans. 

Establish  the  mitigation  plans  for  the  risks. 

Example  methods: 

•  cause  and  effect  diagrams 

•  brainstorming 

•  cost  estimating 

•  pert  charting 

Note:  A  joint  risk  is  one  that  requires  action  or  attention  by 
both  customer  and  supplier. 


Monitor  risk  indicators  and  mitigation  plans.  Indicators  and 
trends  provide  information  to  activate  plans  and 
contingencies.  These  are  also  reviewed  periodically  to 
measure  progress  and  identify  new  risks. 

Maintain  visibility  of  risks,  project  priority,  and  mitigation 
plans. 

Example  methods: 

•  risk-driven  technical  performance  measures 

•  performance  trend  charts 


Team  Risk 
Management 
Functions, 
continued 


Function 

Description 

Control 

Correct  for  deviations  from  the  risk  mitigation  plans.  Actions 
can  lead  to  corrections  in  products  or  processes.  Any  action 
may  lead  to  joint  resolution.  Changes  to  risks,  risks  that 

become  problems,  or  faulty  plans  require  adjustments  in  plans 

SO,,!— <22 — ^  r'') 

or  actions. 

Maintain  the  level  of  risk  that  is  acceptable  to  the  program 
managers. 

Example  methods: 

•  action  plans 

•  decision  trees  and  tables 

Communicate 

Provide  information  and  feedback  internal  and  external  to  the 
project  on  the  risk  activities,  current  risks,  and  emerging  risks. 

_ 

Communication  occurs  formally  as  well  as  informally. 

Establish  continuous,  open  communication.  Formal 

communication  about  risks  and  action  plans  is  integrated  into 

existing  technical  interchange  meetings,  design  reviews,  and 
user  requirements  meetings. 

Example  formal  processes: 

•  Team  Review:  Quarterly  review  meetings  to  evaluate 
status,  new  risks,  priorities,  and  action  plans. 

•  Joint  Action  Planning:  Joint  activity  to  develop 
mitigation  plans  for  joint  risks. 

Nol?:  Example  methods  are  the  same  as  those  listed  in 
Analyze  and  Plaa 

Scenario  Comparing  Team  Risk  Management  to 
Risk  Management 

Introduction  Team  Risk  Management  builds  on  the  principles  and  functions  of  risk  management 

by  adding  teamwork. 

Comparison  To  show  the  differences  between  Team  Risk  Management  and  risk  management,  a 

Scenario  scenario  of  how  a  risk  would  be  handled  in  each  is  compared.  The  table  below  lists 

each  Team  Risk  Management  function  and  describes  a  typical  activity  in  risk  man¬ 
agement  compared  to  a  typical  activity  in  Team  Risk  Management. 


Function 

In  Risk  Management 

In  Team  Risk  Management 

Initiate 

There  is  no  comparable 
activity  (the  first  activity  is  to 
identify  risks). 

Customer  requests  the 
supplier  to  execute  risk 
management  as  a  team. 

Customer  separately 
identifies  the  project  risks. 

Supplier  separately  identifies 
the  project  risks. 

Team 

There  is  no  comparable 
activity  (the  first  activity  is  to 
identify  risks). 

Customer  and  supplier  do 
team  building. 

Customer  and  supplier 
formally  constitute  a 
management  team  to  conduct 
Team  Reviews. 

Identify 

Supplier  identifies  risk  of 
inadequate  time  in  the  test  lab 
prior  to  system  delivery. 

Supplier  identifies  risk  of 
inadequate  time  in  the  test 
lab  prior  to  system  delivery. 

Analyze 

Supplier  identifies  this  risk  as 
first  priority. 

Supplier  reviews  risk  with 
customer  at  Team  Review. 

Customer  and  supplier 
jointly  determine  the  risk  to 
be  5th  in  a  set  of  20  top 
program  risks. 

Comparison 

Scenario, 

continued 


Function 

In  Risk  Management 

In  Team  Risk  Management 

Plan 

Supplier  plans  to  reorder  test 
schedule  to  ensure  critical 
elements  are  tested  first  in  case 
risk  proves  true. 

Customer  and  supplier 
jointly  plan  to  have: 

•  supplier  reorder  tests 

•  customer  locate  &  secure 
contingency  test  lab 

Track 

Test  schedule  is  reordered. 

Each  test  event  and  planned 
action  is  monitored  jointly 
for  follow-up. 

Control 

Risk  proves  true. 

Supplier  asks  for  delay  in 
delivery  time  to  complete 
testing. 

Risk  proves  true. 

Supplier  makes  use  of 
contingency  lab  for  the  rest 
of  testing. 

Communicate 

Internal  communications  are 
open. 

Issues  are  shared  with  the 
customer  on  a  case-by-case 
basis.  The  test  schedule  does 
not  come  up  until  the  supplier 
asks  for  a  delay. 

Internal  communications  are 
open. 

Communications  between 
customer  and  supplier  are 
open. 

Customer  and  supplier  know 
ahead  of  the  decision  the  risk 
and  alternative  actions  to 
take. 

Results 

System  delivery  is  delayed  to 
allow  for  complete  testing. 

System  is  delivered  on  time, 
completely  tested. 

Customer  and  supplier  now 
know  each  other’s  point  of 
view  and  both  share  a 
common  set  of  priorities. 
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Advantages  of  Team  Risk  Management 

Introduction  Team  Risk  Management  offers  a  number  of  advantages  for  a  project,  as  compared 

to  individual  or  group  risk  management.  However,  it  also  involves  a  change  from 
past  management  practices  and  past  customer-supplier  (government-contractor)  re¬ 
lationships,  and  this  will  require  new  commitments  by  both.  These  new  commit¬ 
ments,  in  turn,  may  involve  investment  -  particularly  early  in  the  program. 

Advantages  and  The  following  table  highlights  the  advantages  of  Team  Risk  Management  and  also 

Commitments  identifies  what  commitment  would  be  required  by  the  team  (customer  and  supplier) 

to  achieve  the  advantage. 


Advantage 

Description 

Required  Commitment 

Improved 

communica¬ 

tions 

The  aspect  of  routine 
communications  includes  both 
customer  and  supplier.  Risks 
are  treated  by  all  as 
depersonalized  issues  that 
threaten  the  common  goal  of  a 
successful  program. 

By  openly  sharing  risks,  both 
the  customer  and  supplier  are 
able  to  draw  on  each  other’s 
resources  in  mitigating  risks 
and  enabling  rapid  response  to 
developing  risks  or  problems. 

Move  beyond  finger 
pointing  and  resolve 
project  risks  as  a  joint 
responsibility. 

Encourage  all  forms  of 
communications  (e.g., 
telephone  and  electronic 
mail)  among  all  team 
members. 

Encourage  all  to  explore 
what  could  cause  the 
program  to  go  off  track. 

Allow  for  more  meetings 
and  more  travel  initially. 

Multiple 
perspectives  on 
risks 

Team  members  are  not  limited 
to  looking  for  mitigation  strate¬ 
gies  among  their  own  limited 
areas  of  control. 

Bringing  both  customer  and 
supplier  together  in  mitigating 
risks  opens  doors  to  strategies 
that  both  can  do  together,  but 
that  neither  could  do  alone. 

Accept  the  philosophy 
that  the  team  can  arrive  at 
better  solutions  than  any 
individual — even  the 
program  manager — can 
alone. 
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Advantages  and 

Conunitments, 

continued 


Advantage 

Description 

Required  Commitment 

Broader  base  of 
expertise 

The  combination  of  customer 
and  supplier  brings  together  a 
richer  pool  of  experience  in 
perceiving  and  dealing  with 
risks 

The  customer  often  brings 
better  perspectives  on  the 
application  domain  and 
“what’s  possible  to  change.” 

The  supplier  often  brings  better 
perspectives  on  the  technical 
domain  and  “what’s  possible  to 
do.” 

Accept  all  the  unique 
perspectives  that  others 
bring  to  the  table. 

Broad-based 

buy-in 

Risks  and  mitigation  strategies 
are  cooperatively  determined 
by  the  team  (customer  and 
supplier),  so  all  accept  the 
results  of  the  process.  “Second 
guessing”  and  criticism  after 
the  fact  are  eliminated. 

Over  time  trust  develops  and 
expectations  are  realized.  This 
paves  the  way  for  strengthened 
relationships  and  the  power  of 
teamworic. 

Encourage  and  allow  teams 
to  meet,  discuss,  and  agree. 

Invest  in  improving 
meeting  skills. 

Use  outside  facilitation  as 
required. 

Risk 

consolidation 

Structured  methods  bring 
together  risks  identified  in  each 
organization,  giving  decision 
makers  a  more  global 
perspective  and  highlighting 
areas  of  common  interest  and 

concern. 

Accept  that  risk  is  inherent 
in  enterprise. 

Abandon  the  notion  that 
risks  should  not  be 
discussed  until  a  mitigation 
strategy  has  been  identified. 

Answers  to  Frequently  Asked  Questions 


How  to  Start? 


How  Long? 


How  can  I  start  Team  Risk  Management  in  my  organization? 

Typically,  the  SEI  approach  to  installing  Team  Risk  Management  is  a  four-step  pro¬ 
cess,  as  is  illustrated  in  the  figure  below. 


^ommitment^ 


^  Baseline  ^ 


^  Installation^ 


^  Closure  ^ 


1 .  Establish  awareness  and  commitment 

2.  Establish  a  baseline  of  existing  practices  and  existing  risks. 

3.  Install  and  adapt  the  Team  Risk  Management  methods  to  existing  project  man¬ 
agement. 

4.  Mutually  come  to  closure  with  a  defined  and  established  risk  management  pro¬ 
cess  with  formal  training. 


How  long  will  it  take  to  install  Team  Risk  Management  in  my  organization? 

We  believe  that  once  the  commitment  is  made  and  the  change  accepted,  18  to  24 
months  should  provide  the  necessary  time  to  install,  adapt,  and  train  the  Team  Risk 
Management  methods. 

Note:  The  acceptance  of  change  is  key  to  effectively  installing  Team  Risk  Manage¬ 
ment. 


When  to  Start? 


More  Informa¬ 
tion? 


When  should  I  start? 

The  earlier  the  better.  The  quicker  you  begin  to  manage  risks, 

•  the  greater  opportunity  you  have  to  mitigate  risks 

•  the  better  are  your  alternatives 

•  the  greater  are  your  chances  of  avoiding  cost  and  schedule  impacts 

The  greatest  leverage  is  at  the  front  end  of  the  life  cycle  by  making  risks  and  risk 
management  a  visible  part  of  the  project  from  the  beginning  as  a  recognized  part  of 
acquisition  and  development. 

How  can  I  get  more  information? 

Contact  SEI  Customer  Relations: 

Customer  Relations 
Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213-3890 
Internet:  customer-relations  @sei.cmu.edu 
Phone:  (412)  268-5800 
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